WARNING:
JavaScript is turned OFF. None of the links on this concept map will
work until it is reactivated.
If you need help turning JavaScript On, click here.
此概念图以 IHMC CmapTools 创建, 内含信息有关于: 第14章 設計模式與框架, 14-1-3 設計模式與框架-差異 是 設計模式與框架的主要差異,如下所示: 設計模式比框架更抽象化。 設計模式比起框架來說,它是一種更小的架構 元素。 設計模式比框架擁有更高的適用性,因為設計 模式並沒有針對特定類型的軟體系統。, Singleton模式是一種建構模式,保證類別只擁 有一個存在的實例,可以提供全域指標來存取 此實例,如下圖所示: 實作 Java語言實作Singletion模式的程式碼,如下所示: public class Singleton { private static final Singleton INSTANCE = new Singleton(); // Private建構子 private Singleton() { } public static Singleton getInstance() { return INSTANCE; } }, 14-1-1 SOLID物件設計原則-說明 是 在說明設計模式之前,讓我們先來看一看 「物件設計原則」(Object Design Principle ),也就是著名的SOLID原則,這是由 Robert C. Martin(著名的Uncle Bob)提出的 五個物件導向設計的基本原則。, 14-4 使用設計模式 包括 14-4-5 Strategy模式-說明, 資訊專家模式(Information Expert Pattern)是用 來解決如何決定哪一個物件負責執行特殊的行 為,可以幫助我們決定和了解哪一個類別有責 任執行此行為。專家模式的原則為: 「將責任指定給資訊專家,即擁有資訊的哪一 個類別,必須完成責任。」 例如 例如:訂購商品的UML類別圖包含:訂單、訂 單明細和商品共三個類別,如下圖所示:, 14-4-4 State模式-說明 是 State模式屬於一種行為模式,允許物件因內部 的狀態改變而改變其行為。State模式可以將每 一個狀態建立成物件,讓它們自行負責狀態切 換的行為,如下圖所示:, 相依反轉原則是指類別需要依賴抽象類別, 而不是實體類別。也就是說,在商業邏輯的 高階類別不能依賴低階類別,而是應該依賴 抽象化的抽象類別或介面,因為抽象化 (Abstraction)才是物件設計的王道。一般來 說,DIP原則的目的常常是為了能夠達成OCP 原則。 例如 例如:車輛在商業邏輯來看,是一種高階類 別,依賴低階類別的引擎和輪胎,如下圖所 示:, 14-1 設計模式與框架的基礎 包括 14-1-1 SOLID物件設計原則-說明, 14-2-1 資訊專家模式-說明 是 資訊專家模式(Information Expert Pattern)是用 來解決如何決定哪一個物件負責執行特殊的行 為,可以幫助我們決定和了解哪一個類別有責 任執行此行為。專家模式的原則為: 「將責任指定給資訊專家,即擁有資訊的哪一 個類別,必須完成責任。」, 14-4 使用設計模式 包括 14-4-6 Flyweight模式-說明, 例如:車輛在商業邏輯來看,是一種高階類 別,依賴低階類別的引擎和輪胎,如下圖所 示: 修改為 車輛類別是依賴引擎和輪胎的實體類別,並 不是抽象化的抽象類別或介面,違反DIP原 則。我們可以將車輛類別從依賴實體類別, 轉為依賴介面,所有符合四行程規格的引擎 (福特引擎、裕隆引擎)和17吋輪胎(米其 林輪胎)都可以用來建立車輛,如下圖所示 :, 14-2-3 控制者模式-說明 是 控制者模式(Controller Pattern)是決定哪一 個非使用介面類別(Non-UI Class)負責處理 系統事件,其觀念類似Ivar Jacobson的控制類 別。 雖然在軟體系統中會有很多物件都可以接收 系統事件,但並不表示它們都需要處理此事 件,Larman建議這些事件應該由符合下列條 件的類別來處理,如下所示: 類別代表整個系統、裝置或子系統,稱為 Facade控制者。 在系統事件產生時,代表使用案例情節的類 別,它是位在動作者和商業類別之間的類別 ,稱為使用案例控制者(Use Case Controller ),其名稱通常是在使用案例名稱之後加上 控制、管理或操作。, 14-2-2 建立者模式-說明 是 建立者模式(Creator Pattern)是在決定誰負責 建立特定類別的實例,當類別A有責任建立類 別B的實例時,物件A就是物件B的建立者, 若: 物件A包含物件B。 物件A緊密使用物件B。 物件A擁有初始資料需要傳遞給物件B。, 14-1 設計模式與框架的基礎 包括 14-1-4 設計模式的描述-內容, 14-4-1 Factory Method模式-說明 是 Factory Method模式屬於一種建構模式,它是 模擬工廠生產產品的模式,生產的產品是一 個一個物件。Factory Method模式是定義一個 介面來建立物件,但是讓繼承的子類別來決 定建立哪一種類別的物件,如下圖所示:, 控制者模式(Controller Pattern)是決定哪一 個非使用介面類別(Non-UI Class)負責處理 系統事件,其觀念類似Ivar Jacobson的控制類 別。 雖然在軟體系統中會有很多物件都可以接收 系統事件,但並不表示它們都需要處理此事 件,Larman建議這些事件應該由符合下列條 件的類別來處理,如下所示: 類別代表整個系統、裝置或子系統,稱為 Facade控制者。 在系統事件產生時,代表使用案例情節的類 別,它是位在動作者和商業類別之間的類別 ,稱為使用案例控制者(Use Case Controller ),其名稱通常是在使用案例名稱之後加上 控制、管理或操作。 例如 例如:在上一節新增訂單項目的循序圖,新 增【訂單項目控制】物件來面對介面層,它 就是一個控制者,如下圖所示:, 14-1-1 SOLID物件設計原則- 相依反轉原則(DIP:Dependency Inversion Principle) 是 相依反轉原則是指類別需要依賴抽象類別, 而不是實體類別。也就是說,在商業邏輯的 高階類別不能依賴低階類別,而是應該依賴 抽象化的抽象類別或介面,因為抽象化 (Abstraction)才是物件設計的王道。一般來 說,DIP原則的目的常常是為了能夠達成OCP 原則。, 例如:長方形類別可以計算長方形面積和繪 出長方形圖形,繪圖程式類別是使用其繪圖 方法;面積計算器類別是使用其面積方法, 如下圖所示: 問題是 我們可以看出長方形類別執行的是兩種責任 ,這會產生一些問題,如下所示: 面積計算器類別只是單純計算面積,並沒有 繪圖,但是因為長方形類別會使用GUI類別 的繪圖功能,所以仍然需要包含此類別。 當我們更改長方形類別時,繪圖程式類別可 能需要更改;面積計算器類別也可能需要更 改,相反的也一樣。, 14-3 Gang of Four設計模式 包括 14-3-1 設計模式的種類, 14-1 設計模式與框架的基礎 包括 14-1-1 SOLID物件設計原則- 單一責任原則(SRP:Single Responsibility Principle)